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A Standard for the Transmission of 802.2 Packets over IPX Networks 


Status of this Memo 


This document specifies a standard method of encapsulating 802.2 [1] 
packets on networks supporting Novell’s Internet Packet Exchange 
Protocol [2] (IPX). It obsoletes earlier documents detailing the 
transmission of Internet packets over IPX networks. It differs from 
these earlier documents in that it allows for the transmission of 
multiple network protocols over IPX and for the transmission of 
packets through IPX bridges. Distribution of this memo is unlimited. 


Introduction 


The goal of this specification is to allow compatible and 
interoperable implementations for transmitting Internet packets such 
as the Internet Protocol [3] (IP) and Address Resolution Protocol [4] 
(ARP) as well as the Connectionless-—mode Network Protocol [5] (CLNP) 
over IPX networks. 


IPX is a proprietary standard developed by Novell derived from 
Xerox’s Internet Datagram Protocol [6] (IDP). Defining the 
encapsulation of the IEEE 802.2 Data Link Layer Standard over IPX in 
terms of yet another 802.X Physical Layer standard allows for the 


transmission of IP Datagrams as described in RFC 1042 [7]. This 
document will focus on the implementation of that RFC over IPX 
networks. 

Description 


In general, this specification allows IPX networks to be used to 
support any network protocol which can use the IEEE 802.2 Data Link 
Layer specification. 


More specifically, IPX networks may be used to support IP networks 


and subnetworks of any class. By encapsulating IP datagrams within 
IPX datagrams and assigning IP numbers to the hosts on a IPX network, 
IP-based applications are supported on these hosts. The addition of 


an IP Gateway capable of encapsulating IP packets within 802.IPX 
datagrams would allow those hosts on an IPX network to communicate 
with the Internet. 
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Maximum Transmission Unit 


The maximum data size of a IPX datagram is 546 bytes. As the 
combined size of the 802.2 LLC and SNAP headers is 8 bytes, this 
results in a Maximum Transmission Unit (MTU) of 538 bytes. 


Address Mappings 


The mapping of Internet Protocol addresses to 802.IPX addresses is 
done using the Address Resolution Protocol in the same fashion as 
with other IEEE 802.X physical addresses. However, the length of an 
802.IPX physical address is 10 bytes rather than 2 or 6. This 10 
byte physical address consists of the 4 bytes of the IPX network 
address followed by the 6 bytes of the IPX node address. 


Byte Order 
The byte transmission order is "big-endian" [8]. 

Broadcast Addresses 
IPX packets may be broadcast by setting the IPX header Packet Type 
field to 0x14, the Destination Network field to the local network 


number, the the Destination Node field to Oxffffff, and the Immediate 
Address field of the IPX Event Control Block to Oxffffff. 


Unicast Addresses 
IPX packets may be unicast by setting the IPX header Packet Type 
field to 0x04, the Destination Network field and Destination Node 
field to those values found by address resolution, and the Immediate 
Address field of the IPX Event Control Block to the physical address 
of the destination node or the appropriate IPX bridge. 

Checksum 


Like most IPX applications, this specification does not use IPX 
checksum. 


Reserved values 


The IPX socket 0x8060 has been reserved by Novell for the 
implementation of this protocol. 


Implementation 


The encapsulation of Internet packets within IPX networks has proved 
to be quite useful. Because the IPX interface insulates knowledge of 
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the physical layer from an application, 802.2 over IPX networks work 
over any physical medium. A typical IP over IPX packet is shown 
below: 


N bytes | physical header | 
Te Reader | 

8 bytes | 802.2 header 

usually 20 bytes ener ea 
usually 20 bytes ee ee 
up to 498 bytes aoe ieee | 


On workstations supporting an IPX programming interface, 
implementation of this specification has proved fairly 
straightforward. The only change which was done was to modify the 
existing address resolution protocol code to allow for cache entries 
larger than the hardware address length. This was done to allow room 
for the immediate address of a possible intervening IPX bridge in 
addition to the destination node and network addresses to be 
associated with a given IP address. 


Thus far, no implementations have been attempted on systems which do 
not already support an IPX programming interface (e.g., a dedicated 
router) though a few implementation details can be noted. First, 
obviously any such implementation will have to distinguish IPX 
packets from other packets; this process will be media dependent. 
Second, note that no unicast packet is ever sent from hostl to host2 
without a prior broadcast packet from host2 to hosti. Thus, the 
immediate address of a possible intervening IPX bridge between host1l 
and host2 can be learned from the physical header of that prior 
broadcast packet. Third, any such implementation will need to 
discover the local IPX network number from a Novell bridge or file 
server. The mechanisms for doing this exist but documentation for 
their use is not commonly available. 
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Security Considerations 


Security issues are not addressed in this memo. 
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